Layered Architecture ​
Components within the layered architecture style are organized into horizontal layers, each performing a specific role within the application. Although the number of layers may vary, most layered architectures consist of four standard layers: presentation, business, persistence, and database. In some cases, the business layer and persistence layer are combined into a single business layer, particularly when the persistence logic (such as SQL) is embedded within the business layer components.
Each layer of the layered architecture style has a specific role and responsibility within the application.
Each layer in the architecture forms an abstraction around the work that needs to be done to satisfy a particular business request. For example, the presentation layer doesn’t need to know about how to get customer data; it only needs to display that information on a screen in a particular format.
Layers are usually manifested through a namespace, package struc ture, or directory structure (depending on the implementation language used).
One of the powerful features of the layered architecture style is the separation of concerns among components. Components within a specific layer deal only with logic that pertains to that layer.
Layers of Isolation ​
Layers can be Open or Closed. A closed layer means that as a request moves from layer to layer, it must go through the layer right below it to get to the next layer below that one. eg. Requests from Presentation layer has to go through Business logic layer before accessing the Persistence/Database layers.
The layers of isolation concept means that changes made in one layer of the architecture generally don’t impact or affect components in other layers: the change is isolated to the components within that layer, and possibly another associated layer.
This makes it easier to refactor one layer (like changing presentation layer from React to Vue) independent of the business logic layer.
While closed layers facilitate layers of isolation and therefore help isolate change within the architecture, there are times when it makes sense for certain layers to be open. eg. A layer containing shared services and utilities that can be accessed by the Business Logic layer.
If a layer is marked open, the layer above it can directly bypass it and go to the next layer below it.
| Closed Layers | Open Layers |
|---|---|
 |  |
The Architecture Sinkhole Anti-Pattern ​
Every layered architecture will have at least some scenarios that fall into The Architecture Sinkhole Anti-Pattern. The key, however, is to analyze the percentage of requests that fall into this category. The 80-20 rule is usually a good practice to follow to determine whether or not you are experiencing the architecture sinkhole anti-pattern.
If your overall team structure is organ ized as teams of presentation (UI) developers, backend developers, shared services teams, database teams, and so on, this aligns well to the overall partitioning of this architecture style (presentation layer, business layer, persistence layer, and so on). This alignment is known as Conway's Law.
Issues with Layered Architecture ​
Lower Scalability, Elasticity, Fault Tolerance and Performance. This is because of this architecture being monolithic.
While the layered architecture can sometimes scale by split ting the layers into separate physical deployments and/or creating separate instances of the application in multiple virtual machines, it becomes very expensive and inefficient because 100% of the application functionality must scale.
The layered architecture is not very fault-tolerant—a fatal crash in any part of the application brings down the entire application functionality.